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100. EXECUTION ENVIRONMENT CONTROL DETERMINES 
WHETHER IT HAS A STUB CLASS APPROPRIATE FOR THE 
REMOTE METHOD FOR WHICH IT HAS A REFERENCE 



NO 



YES 



101. CONTINUE 



102. CONTROL MODULE DETERMINES WHETHER 
INVOCATION INCLUDED A RESOURCE IDENTIFIER OR 
IF A RESOURCE IDENTIFIER FOR THE CALL IS OTHER- 
WISE PROVIDED 



YES 



1 03. CONTROL MODULE ENABLES STUB CLASS LOADER 
TO INITIATE COMMUNICATIONS WITH IDENTIFIED SERVER 
COMPUTER TO OBTAIN STUB CLASS INSTANCE FOR THE 
CLASS AND METHOD TO BE INVOKED 



NO 



104. WHEN STUB CLASS LOADER RECEIVES STUB 
CLASS INSTANCE, CONTROL MODULE LOADS IT INTO 
EXECUTION ENVIRONMENT 




FIG. 2 
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110. CONTROL MODULE USES STUB CLASS LOADER IS 
CALLED TO, IN TURN, CALL DEFAULT STUB CLASS 
INSTANCE IS TO LOCATE APPROPRIATE SERVER 
COMPUTER, INCLUDING IDENTIFICATION OF CLASS 
AND METHOD TO BE INVOKED 



111. NAMESERVER COMPUTER PROCESSES 
COMMUNICATIONS FROM DEFAULT STUB CLASS 
INSTANCE AS A REMOTE METHOD INVOCATION, 
TO OBTAIN RESULT INFORMATION 



112. NAMESERVER COMPUTER INITIATES 
COMMUNICATIONS TO PROVIDE THE RESULT 
INFORMATION TO THE DEFAULT STUB CLASS INSTANCE 



0 



FIG. 2 (CONT. A) 
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113. RESULT INFORMATION IS PROVIDED TO STUB 
CLASS LOADER 



114. STUB CLASS LOADER DETERMINES WHETHER 
RESULT INFORMATION IS A RESOURCE IDENTIFIER OR 
AN INDICATION THAT NO RESOURCE IDENTIFIER EXISTS 
FOR THE CLASS AND METHOD 



RESOURCE 



IDEN1 



IFIER 



NO RESOURCE 
IDENTIFIER 



115. EXCEPTION 



J 



FIG. 2 (CONT. B) 
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120. EXECUTION ENVIRONMENT CONTROL VERIFIES 
THAT IT HAS STUB CLASS INSTANCE FOR REMOTE 
METHOD WHICH HAS BEEN INVOKED 



YES 



121. CALL INTERFACE PROVIDED BY STUB CLASS 
INSTANCE TO INVOKE REMOTE METHOD PROVIDING 
PARAMETER VALUES WHICH ARE TO BE USED IN 
PROCESSING THE REMOTE METHOD 



122. STUB CLASS INSTANCE FOR REMOTE METHOD TO 
BE INVOKED INITIATES COMMUNICATIONS WITH SERVER 
COMPUTER WHICH MAINTAINS CLASS FOR REMOTE 
METHOD, IN THE PROCESS PASSING PARAMETER 
VALUES WHICH ARE TO BE USED IN PROCESSING THE 
REMOTE METHOD 



123. SERVER COMPUTER ESTABLISHES AN EXECUTION 
ENVIRONMENT FOR METHOD TO BE INVOKED, USES 
INFORMATION PROVIDED BY SKELETON TO CREATE A 
CLASS INSTANCE FOR THE CLASS WHICH MAINTAINS 
THE METHOD TO BE INVOKED 



0 



0 
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124. SERVER COMPUTER PROCESSES THE METHOD IN 
CONNECTION WITH PARAMETER VALUES PROVIDED BY 
STUB CLASS INSTANCE 



125. SERVER COMPUTER INITIATES COMMUNICATIONS 
WITH THE STUB CLASS INSTANCE TO PROVIDE RESULT 
INFORMATION TO THE STUB CLASS INSTANCE 



126. STUB CLASS INSTANCE RECEIVES RESULT AND 
PROVIDES RESULT INFORMATION TO CALLING CLASS 
INSTANCE 



127. EXCEPTION 



J 



FIG. 3 (CONT. A) 
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SYSTEM AND METHOD FOR workstations in the network. Such a network may be spread 

FACILITATING DYNAMIC LOADING OF over a fairly wide area, with the personal computers/ 

STUB INFORMATION TO ENABLE A workstations being interconnected by communication links 

PROGRAM OPERATING IN ONE ADDRESS such as electrical wires or optic fibers. 

SPACE TO INVOKE PROCESSING OF A 5 l n addition to downloading information from servers for 

REMOTE METHOD OR PROCEDURE IN processing, a client, while processing a program, can 

ANOTHER ADDRESS SPACE remotely initiate processing by a server computer of par- 
ticular routines and procedures (generally "procedures"), in 

INCORPORATION BY REFERENCE connection with certain "parameter" information provided 

Tliis application is a Continuation under 37 C.F.R. 1.53(b) 10 b ? 4* clienl ; MieT ^ has P™**** 1 the procedure 

of U.S. patent application Ser. No. 08/636,706, filed on Apr. * ^ P r0Vlde «suUs of its processing to the client, which 

23 1996 the client may thereafter use in its processing operations. 

L T ™ , c /c . Typically in such "remote procedure calls" the program will 

i Jo^Z ^SMge Spec'fkanon (Sun Microsystems, make ^ 0 f a local "stub" which, when called, transfers the 

Inc.,1993-9^(heremafterreferredtoas he "Java language 35 tQ lfae ^ which { lements ^ rticular 

specification ) incorporated herein by reference. procedure, receives the results and provides them to the 

The Java Virtual Machine Specification (Sun program. Conventionally, the stub must be compiled with 

Microsystems, Inc., 1993-95), (hereinafter referred to as the the program, in which case the information needed to call 

"Java virtual machine specification") incorporated herein by the remote procedure must be determined at compile time, 

reference. 20 rather than at the time the program is run. Since the stub 

Ann Wolirath, et al., "A Distributed Object Model for available to the client's programs is static, it may be at best 

Java™," incorporated herein by reference. the closest that can be determined should be provided for the 

U.S. patent application Sen No. 08/636,707, filed on Apr. program when it (the program) is compiled. Accordingly, 

23, 1996 in the names of James H. Waldo, Krishna Bharat errors ^ inefficiencies can develop due to mismatches 

and Roger Riggs, and entitled "System And Method For 25 between the stub that is provided to a program and the 

Generating Identifiers For Uniquely Identifying Object requirements of the remote procedure that is called when the 

Types For Objects Used In Processing Of Object-Oriented program is run. 

Programs And The Like" now U.S. Pat. No. 5,815,709, SUMMARY OF THE INVENTION 

incorporated herein by reference. ^ . 

30 The invention provides a new and improved system and 

FIELD OF THE INVENTION method for facilitating the obtaining and dynamic loading of 

a stub provided to enable a program operating in one address 

The invention relates generally to the field of digital space to remotely invoke processing of a method or proce- 

computer systems, and more particularly to systems and dure in another address space, so that the stub can be loaded 

methods for facilitating the invocation by a program being 35 by the program when it is run and needed, rather than being 

processed by a computer in one address space, of processing statically determined when the program is compiled. Indeed, 

of methods and procedures in another address space, which the stub that is loaded can be obtained from the resource 

may be implemented either on the same computer or on providing the remote method or procedure, and so it (the 

another computer. The invention particularly provides a stu b) can exactly define the invocation requirements of the 

system and method for obtaining and dynamically loading ^ remote method or procedure. Since the stub can be located 

"stub" information which facilitates invocation by a pro- an d dynamically loaded while the program is being run, 

gram operating in one address space of a remote method or ratrj er that being statically determined when the program is 

procedure in another address space, and possibly on another compiled, run-time errors and inefficiencies which may 

computer. result from mis-matches between the stub that is provided 

BACKGROUND OF THE INVENTION 45 8Dd "* ^ re ™ nls ° f lhe ^mote method or procedure that 

is invoked can be minimized. 

In modern "enterprise" computing, a number of personal In brief summary, the invention provides a stub retrieval 
computers, workstations, and other devices such as mass and loading subsystem for use in connection with a remote 
storage subsystems, network printers and interfaces to the method invocation system. The stub retrieval and loading 
public telephony system, are typically interconnected in one 50 subsystem controls the retrieval and loading of a stub for a 
or more computer networks. The personal computers and remote method, into an execution environment, to facilitate 
workstations are used by individual users to perform pro- invocation of the remote method by a program executing in 
cessing in connection with data and programs that may be the execution environment. The stub retrieval subsystem 
stored in the network mass storage subsystems. In such an includes a stub retriever for initiating a retrieval of the stub 
arrangement, the personal computers/workstations, operat- 55 and stub loader for, when the stub is received by the stub 
ing as clients, typically download the data and programs retriever, loading the stub into the execution environment, 
from the network mass storage subsystems for processing. thereby to make the stub available for use in remote invo- 
In addition, the personal computers or workstations will cation of the remote method. In one embodiment, the stub 
enable processed data to be uploaded to the network mass retrieval and loading subsystem effects the retrieval and 
storage subsystems for storage, to a network printer for 60 loading for a program operating in one address space 
printing, to the telephony interface for transmission over the provided by one computer, of stub class instances to effect 
public telephony system, or the like. In such an arrangement, the remote invocation of methods which are provided by 
the network mass storage subsystems, network printers and objects operating in another address space, which may be 
telephony interface operate as servers, since they are avail- provided by the same computer or a different computer. In 
able to service requests from all of the clients in the network. 65 that same embodiment, the stub retrieval and loading sub- 
By organizing the network in such a manner, the servers are system effects the retrieval and loading of a stub class 
readily available for use by all of the personal computers/ instance when the remote object is referenced, although in 
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other embodiments retrieval and loading may be effected 
when the remote method is invoked. 

BRIEF DESCRIPTION OF THE DRAWINGS 

This invention is pointed out with particularity in the 
appended claims. The above and further advantages of this 
invention may be better understood by referring to the 
following description taken in conjunction with the accom- 
panying drawings, in which: 

FIG. 1 is a function block diagram of a computer network 
including an arrangement constructed in accordance with the 
invention for facilitating the obtaining, dynamic loading and 
use of "stub" information to enable a program operating in 
one address space to invoke processing of a remote method 
or procedure in another address space; 

FIGS. 2 and 3 are flow charts depicting the operations 
performed by the arrangement depicted in FIG. 1, which is 
useful in understanding the invention, with FIG. 2 depicting 
operations performed in connection with obtaining and 
dynamic loading of the stub information and FIG. 3 depict- 
ing operations performed in connection with use of the stub 
information to invoke processing of the remote method or 
procedure. 

DETAILED DESCRIPTION OF AN 
ILLUSTRATIVE EMBODIMENT 

FIG. 1 is a schematic diagram of a computer network 10 
including an arrangement for facilitating dynamic loading of 
"stub" information to enable a program operating in one 
address space to remotely invoke processing of a method or 
procedure in another address space. With reference to FIG. 
1, computer network 10 includes a plurality of client com- 
puters U(Q through 11(N) (generally identified by reference 
numeral ll(n)), a plurality of server computers 12(1) through 
12(M) (generally identified by reference numeral 12(m)), all 
of which are interconnected by a network represented by a 
communication link 14. In addition, the network 10 may 
include at least one nameserver computer 13, which may 
also be connected to communication link 14, whose purpose 
will be described below. As is conventional, at least some of 
the client computers ll(/i) are in the form of personal 
computers or computer workstations, each of which typi- 
cally includes a system unit, a video display unit and 
operator input devices such as a keyboard and mouse (all of 
which are not separately shown). The server computers 
12(m) and nameserver computer 13 also typically include a 
system unit (also not separately shown), and may also 
include a video display unit and operator, input devices. 

The client computers 11(«), server computers 12(m) and 
nameserver computer 13 are all of the conventional stored- 
program computer architecture. A system unit generally 
includes processing, memory, mass storage devices such as 
disk and/or tape storage elements and other elements (not 
separately shown), including network interface devices 
15(/i), 16(/n) for interfacing the respective computer to the 
communication link 14. The video display unit permits the 
computer to display processed data and processing status to 
the operator, and an operator input device enables the 
operator to input data and control processing by the com- 
puter. The computers ll(/j) and I2(m) and 13 transfer 
information, in the form of messages, through their respec- 
tive network interface devices 15(«), 16(m) among each 
other over the communication link 14. 

In one embodiment, the network 10 is organized in a 
"client-server" configuration, in which one or more 
computers, shown in FIG. 1 as computers 12(m), operate as 
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servers, and the other computers, shown in FIG. 1 as 
computers H(/i) operate as clients. In one aspect, one or 
more of the server computers 12(m) may, as "file servers," 
include large-capacity mass storage devices which can store 

5 copies of programs and data which are available for retrieval 
by the client computers over the communication link 13 for 
use in their processing operations. From time to time, a 
client computer H(i) may also store data on the server 
computer 12, which may be later retrieved by it (the client 

10 computer that stored the data) or other client computers for 
use in their processing operations. In addition, one or more 
of the server computers 12(m) may, as "compute servers," 
perform certain processing operations in response to a 
remote request therefor from a client computer ll(/i), and 

15 return the results of the processing to the requesting client 
computer for use by them (that is, the requesting client 
computers 11(«)) in their subsequent processing. In either 
case, the server computers may be generally similar to the 
client computers ll(/i), including a system unit, video dis- 

20 play unit and operator input devices and may be usable by 
an operator for data processing operations in a manner 
similar to a client computer. Alternatively, at least some of 
the server computers may include only processing, memory, 
mass storage and network interface elements for receiving 

25 and processing retrieval, storage or remote processing 
requests from the client computers, and generating 
responses thereto. It will be appreciated a client computer 
ll(/i) may also perform operations described herein as being 
performed by a server computer 12(m), and similarly a 

30 server computer 12(m) may also perform operations 
described herein as being performed by a client computer 

"(«)• 

The network represented by communication link 14 may 
comprise any of a number of types of networks over which 

35 client computers ll(/i), server computers 12(m) and 
nameserver computers 13 may communicate, including, for 
example, local area networks (LANs) and wide area net- 
works (WANs) which are typically maintained within indi- 
vidual enterprises, the public telephony system, the Internet, 

40 and other networks, which may transfer digital data among 
the various computers. The network may be implemented 
using any of a number of communication media, including, 
for example, wires, optical fibers, radio links, and/or other 
media for carrying signals representing information among 

45 the various computers depicted in FIG. 1. As noted above, 
each of the computers typically includes a network interface 
which connects the respective computer to the communica- 
tions link 14 and allows it to transmit and receive informa- 
tion thereover. 

50 The invention provides a system for facilitating the 
obtaining and dynamic loading of "stub" information to 
enable a program operating in one address space to invoke 
processing of a remote method or procedure in another 
address space, which may be located on the same computer 

55 as the invoking program or on a different computer. The 
invention will be described in connection with programs 
provided in the Java™ programming language, as described 
in the Java language specification, which are processed in 
connection with an execution environment which is pro- 

60 vided by a Java virtual machine. The Java virtual machine, 
in turn, is specified in the Java virtual machine specification. 
As described in the Java language specification, programs in 
the Java programming language define "classes" and "inter- 
faces." Classes are used to define one or more methods or 

65 procedures, each of which may be invoked by reference to 
an interface. A class may be associated with and extend a 
"super-class," and in that regard will incorporate all of the 
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interfaces and methods of the super-class, and may also class loader 25 to retrieve an un instantiated class for the 

include additional interfaces and/or methods. A class may method to be invoked, from a plurality of uninstantiated 

also have one or more sub-classes (and thus will comprise a classes which are generally identified by reference numeral 

super-class of each of its sub-classes), with each sub-class 27, instantiate it (that is, the uninstantiated class which 

incorporating and possibly extending their respective super- 5 provides the method to be invoked) and link it as a class 

classes. instance 26 into the execution environment. In addition, the 

An interface provides a mechanism by which a set of class loader 25 can discard the class instances 26 when 

methods may be declared. In that connection, an interface processing of the method has terminated. It will be appre- 

identifies each method that is declared by the interface by, ciated mat » ^ class instances 26 has been discarded, it may 

for example, a name, identifies the data type(s) of argument 10 be reloaded by the class loader 25 at a later point if it is then 

(s) that are to be provided for the method, the data type(s) needed. 

of return values that are to be returned by the method, and The structure of nameserver computer 13, if provided, is 

identifiers for exceptions which can be thrown during pro- generally similar to that of the server computer 12(/w), and 

cessing of the method. A class may indicate that it imple- will not be separately described. 

ments a particular interface, and in that connection will 35 To facilitate remote invocation of a method, the control 
include the program code which will be used in processing module 19 of the client computer's execution environment 
all of the methods which are declared in the interface. In 21 makes use of one or more stub class instances generally 
addition, different classes may indicate that they implement identified by reference numeral 30 which are provided as 
the same interface, and each will have program code which part of the execution environment 21 in which the various 
will be used in processing all of the methods which are 2 o class instances 22, including the class instance which is 
declared in the interface, but the program code provided in invoking the remote method, are being processed. Each stub 
each class to for use in processing the methods may differ class instance 30 is an instance of an uninstantiated stub 
from the program code provided in the other classes which class 31, which the server computer 12(m) may maintain for 
is used in processing the same methods; thus, an interface the various class instances 26 and uninstantiated classes 27 
provides a mechanism by which a set of methods can be 2 5 which the server computer 12(m) has "exported," that is, 
declared without providing an indication of the procedure which the server computer 12(/n) makes available to client 
which will be used in processing any of the methods. An computers ll(n) for use in remote invocation of methods 
interface may be declared independently of the particular provided thereby. An uninstantiated stub class 31 includes 
class which implements the method or methods which can declarations for the complete set of interfaces for the par- 
be invoked using the interface. In that regard, a class that 30 ticular remote uninstantiated class 27 which implements the 
invokes the method and a class that actually implements the remote method to be invoked, and also provides or invokes 
method will not need to share a common super-class. methods which facilitate accessing of the remote method(s) 
During processing of a Java program, as described in the which are implemented by the remote class. The uni as tan- 
Java virtual machine specification, a client computer ll(/i) tiated stub class 31, when it is instantiated and provided to 
provides an execution environment 20 for interpreting the 35 the execution environment 20 of the client computer ll(n) as 
Java program. The Java virtual machine includes a class a stub class instance 30, effectively provides the information 
loader 21 that, under control of a control module 19, can which is needed by the control module 19 of the execution 
dynamically link instances of classes, generally identified in environment 20 of the invoking Java program, so that, when 
FIG. 1 by reference numeral 22, into the running program's a remote method that is implemented by its associated class 
execution environment while the program is being executed. 40 is invoked by a Java program running in a particular 
In that operation, the control module 19 effectively enables execution environment, the remote method will be pro- 
the class loader to retrieve uninstantiated classes, which cessed and the return value(s) provided to the invoking Java 
generally identified by reference numeral 23, instantiate program. In one embodiment, the arrangement by which the 
them and link them as class instances 22 into the execution stub class instance may be provided to the execution envi- 
environment's address space at the Java program's run time 45 ronment 20 is similar to that described in the aforementioned 
as the methods which the respective classes 23 implement Waldo, et al., patent application. 

are called. In addition, the class loader 21 can discard ones In addition, the server computer 12(m) provides a skel- 

of the class instances 22 when they are not needed or to eton 32, which identifies the particular classes and methods 

conserve memory. It will be appreciated that, if a class which have been exported by the server computer 12(m) and 

instance 22 has been discarded, it may be reloaded by the 50 information as to how it (that is, the server computer 12(m)) 

class loader 21 at a later point if it is then needed. may load the respective classes and initiate processing of the 

The invention provides an arrangement which facilitates particular methods provided thereby, 

the remote invocation, by a program executing in an execu- When a class instance invokes a remote method main- 

tion environment 20 by a client computer ll(/i), of methods tained by a server computer 12(/w), it will provide values for 

implemented by classes on a server computer 12(m). In 55 various parameters to the stub class instance 30 for the 

executing a method, the server computer 12(m) will also remote method, which values the remote method will use in 

provide an execution environment 24 for processing, under its processing. If the remote method is implemented on the 

control of a control module 28, the Java method. In that same computer as the invoking Java program, when the 

operation, the Java virtual machine which provides the invoking Java program invokes a remote method, the com- 

execution environment 21 includes a class loader 25 (which 60 puter may establish an execution environment, similar to the 

may be similar to the class loader 21) that, under control of execution environment 20, enable the execution environ - 

the control module 28, can dynamically link an instance of ment's class loader to load and instantiate the class which 

the class 26, to enable the method to be processed in the implements the method as a class instance similar to class 

execution environment 24, and instances of other classes instances 22, and process the remote method using values of 

(also generally represented by reference numeral 26) which 65 parameters which are provided by the invoking class 

may be needed to process the remotely-invoked method. In instance in the remote invocation. After processing of the 

that operation, the control module 28 effectively enables the method has been completed, the execution environment in 
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which the remote method has been processed will provide 
the results to the stub class instance 30 for the remote 
method that was invoked, which, in turn, will provide to the 
particular class instance 22 which invoked the remote 
method. 5 

Similar operations will be performed if client computer 
ll(n) and server computer 12(m) are implemented on dif- 
ferent physical computers. In that case, in response to a 
remote invocation, the client computer that is process- 
ing the invoking class instance 22, under control of the 10 
control module 19 for the execution environment 10 for the 
invoking class instance 22, will use the appropriate stub 
class instance 30 to communicate over the network repre- 
sented by the communication link 14 with the server com- 
puter 12(m) which implements the remote method to enable 15 
it (that is, the server computer 12(m)) to establish an 
execution environment 24 for the class which implements 
the remote method, and to use the class loader 25 to load an 
instance of the class as a class instance 26. In addition, the 
client computer ll(/i), also using the appropriate stub class 20 
instance 30, will provide any required parameter values to 
the server computer 12(m) over the network 14. Thereafter, 
the server computer 12(m) will process the remote method 
using parameter values so provided, to generate result value 
(s) which are transferred over the network to the client 2 $ 
computer ll(n), in particular to the appropriate stub class 
instance 30. The client computer 11(h) will, after it receives 
the result value(s) from the network, provide them to the 
invoking class instance 22 for its processing. 

In any case, when the control module 19 of the client 30 
computer's execution environment 20 determines that a 
reference to the remote object has been received, if it 
determines that the stub class instance 30 is not present when 
it receives the reference, it will attempt to obtain the stub 
class instance 30 from, for example, the server computer 35 
12(m) which implements the remote method, and enable the 
stub class instance 30 to be dynamically loaded in the 
execution environment 20 for the invoking class instance 22. 
A reference to the remote object may be received, for 
example, either as a return value of another remote method 40 
invocation or as a parameter that is received during another 
remote method invocation. The stub class instance may be 
dynamically loaded into the execution environment in a 
manner similar to that used to load class instances 22 in the 
execution environment 22. The execution environment 20 is 45 
provided with a stub class loader 33 which, under control of 
the control module 19, will attempt to find and load the stub 
class instances 30 as required by the class instances 22 
processed in the execution environment. The location of a 
particular server computer 12(m) that maintains the class 50 
that implements a method to be invoked remotely may be 
included in the call from the invoking class instance or may 
be made known to the stub class loader 33 through another 
mechanism (not shown) maintained by the client computer 

11(/J). 55 

However, if the stub class loader 33 is not otherwise 
notified of which server computer 12(m) maintains the class 
which implements a method which may be invoked 
remotely, it may use the nameserver computer 13 to provide 
that identification. The identification may comprise any 60 
identifier which may be used to identify a server computer 
12(m) or other resource which is available on the network 14 
and to which the server computer 12(m) can respond. 
Illustrative identifiers include, for example, a network 
address which identifies the server computer and/or 65 
resource, or, if the network 14 is or includes the Internet, an 
identifier to, for example, a World Wide Web resource which 
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may provide the identification or a "uniform resource loca- 
tor" ("URL") which provides a uniform mechanism for 
identifying resources that are available over the Internet. The 
server computer 12(m) which implements the remote 
method, in response to a request from the client computer 
ll(n) will provide stub class instance 30 which the client 
computer 11(«) may load into the execution environment 21 
to thereafter enable the remote invocation to be initiated. 

As noted above, if the stub class loader 33 does not know 
which server computer 12(m) implements the remote 
method which may be invoked (and thus does not know 
which computer is to provide the stub class code for the 
remote invocation), it may, under control of the control 
module 19, obtain the identification from the nameserver 
computer 13. In that operation, the stub class loader 33 may 
use a previously-provided default stub class which is pro- 
vided for use in such cases. The default class stub, when 
used by the invoking Java program, enables the computer 
that is processing the invoking Java program to communi- 
cate with the nameserver computer 13 to obtain information 
which can be used in invoking the remote method. This 
operation is essentially the same as the invocation of a 
remote method to be processed by the nameserver computer 

13, with the remote method including a parameter identify- 
ing the class and method to be remotely invoked, and 
enabling the nameserver computer 13 to provide the iden- 
tification of a server computer 12(m) which can process the 
method to the requesting client computer 11(«) and other 
information which may be helpful in communicating with 
the server computer 12(m) and invoking the particular 
method. It will be appreciated that the nameserver computer 
13 will maintain a table (not separately shown) of 
"exported" resources, that is, resources, such as classes and 
methods, that are available to client computers H(/i) con- 
nected to the network 14, and information, such as the 
identifications of the particular server computers 12(m) 
which provide those resources, which will be useful to the 
client computers ll(/i) in making use of the exported 
resources. 

It will be appreciated that the nameserver computer 13 
may create and maintain the exported resource table in a 
number of ways that are known in the art. For example, the 
nameserver computer 13 may periodically broadcast 
requests for exported resource information over the network 

14, to which the various server computers 12(m) which 
maintain exported resources may respond; in that case, the 
nameserver computer 13 may establish its exported resource 
table based on the responses from the server computers 
12(m). Alternatively, each of the various server computers 
12(m) which maintains an exported resource may periodi- 
cally broadcast information as to the exported resources 
which it maintains, and the nameserver computer 13 can 
update its exported resource table based on the broadcasts 
from the server computer. In addition, the nameserver com- 
puter's exported resource table may be established by a 
system operator and may be fixed until he or she updates it. 

In any case, the information provided by the nameserver 
computer 13 in response to a request initiated by the default 
stub would include such information as, for example, the 
identification of a computer 12(m) which can provide a class 
which implements the remote method to be invoked, par- 
ticular information which the computer (that is, the com- 
puter which implements the remote method) will require to 
provide the required stub class code, and the like. After 
receiving the information from the nameserver computer 13, 
the computer ll(/i) that is processing the invoking Java 
program may, under control of the control module 19, use 
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the information communicate with the computer (that is, the 
computer which implements the remote method) to obtain 
the stub class, and may thereafter invoke the method as 
described above. 

With this background, the operations performed by client 5 
computer ll(n), server computer 12(m) and, if necessary, 
nameserver 13 in connection with obtaining and dynamic 
loading of a stub class instance when a reference to a remote 
method is received will be described in connection with the 
flow chart depicted in FIG. 2. In addition, operations per- 10 
formed by the client computer ll(n) and server computer in 
connection with remote invocation of a method using the 
stub class instance will be described in connection with the 
flow chart depicted in FIG. 3. With reference initially to FIG. 
2, the execution environment control module 19 will, when 15 
it receives a reference to a remote method, will initially 
determine whether an appropriate stub class instance is 
present in the execution environment 20 to facilitate invo- 
cation of the remote method (step 100). If the control 
module 19 determines that such a stub class instance 30 for 2 o 
the remote method is present in the execution environment, 
it may continue other operations (step 101). However, if the 
control module 19 determines in step 101 that such a stub 
class instance is not present in the execution environment 20 
for the remote method, the control module 19 will use the 2 5 
stub class loader 33 to attempt to locate and load a stub class 
instance 30 for the class to process the remote method. In 
that case, the control module 19 will initially determine 
whether the invocation from the class instance 22 included 
a resource locator to identify the server computer 12(/w) or 30 
other resource which maintains the class for the method to 
be invoked, or whether it (that is, the control module 19) or 
the stub class loader 33 otherwise are provided with such a 
resource locator (step 102). If the control module 19 makes 
a positive determination in that step, it will sequence to step 35 
103 to enable the stub class loader 33 to initiate communi- 
cations with identified server computer 12(/n) to obtain stub 
class instance for the class and method to be invoked (step 
103). When the stub class loader 33 receives the stub class 
instance 30 from the server computer 12(/n), it will load the 4 q 
stub class instance 30 into execution environment 20 for the 
class instance 21 which initiated the remote method invo- 
cation call in step 100 (step 104). After the stub class 
instance 30 for the referenced remote method has been 
loaded in the execution environment, the method can be 45 
invoked as will be described below in connection with FIG. 
3. 

Returning to step 102, if the control module 19 determines 
that the invocation from the class instance 22 did not include 
a resource locator to identify the server computer 12(m) or 50 
other resource which maintains the class for the method to 
be invoked, and further that it (that is, the control module 19) 
or the stub class loader 33 is not otherwise provided with 
such a resource locator, a "class not found" exception may 
be indicated, at which point the control module 19 may call 55 
an exception handler. The exception handler may perform 
any of a number of recovery operations, including, for 
example, merely notifying the control module 19 that the 
remote method could not be located and allow it to deter- 
mine subsequent operations. 60 

Alternatively, the control module 19 may attempt to 
obtain a resource locator from the nameserver computer 13 
or other resource provided by the network 14 (generally 
represented in FIG. 1 by the nameserver computer 13), using 
a call to, for example, a default stub class instance 30. The 65 
call to the default stub class instance 30 will include an 
identification of the class and method to be invoked and the 
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name of the nameserver computer 13(m). Using the default 
stub class instance 30, the control module 19 will enable the 
computer ll(/i) to initiate communications with nameserver 
computer 13 to obtain an identifier for a server computer 
12(m) which maintains the class and method to be invoked 
(step 110). The communications from the default stub class 
instance 30 will essentially correspond to a remote method 
invocation, with the method enabling the nameserver com- 
puter to provide the identification for the server computer 
12(m), if one exists associated with the class and method to 
be remotely invoked, or alternatively to provide an indica- 
tion that no server computer 12(m) is identified as being 
associated with the class and method. During the commu- 
nications in step 110, the default stub class interface 30 will 
provide, as a parameter value, the identification of class and 
method to be invoked. 

In response to the communications from the default stub 
class instance 30, the nameserver computer 13 will process 
the request as a remote method (step 111), with the result 
information comprising the identification for the server 
computer 12(m), if one exists that is associated with the class 
and method to be remotely invoked, or alternatively an 
indication that no server computer 12(m) is identified as 
being associated with the class and method. After finishing 
the method, the nameserver computer 13 will initiate com- 
munications with the default stub class instance 30 to 
provide the result information to the default stub class 
instance 30 (step 112). 

After receipt of the result information from the 
nameserver computer 13, the default stub class instance, 
under control of the control module 19, will pass result 
information to the stub class loader 33 (step 113). Thereafter, 
the stub class loader 33 determines whether the result 
information from the nameserver computer comprises the 
identification for the server computer 12(m) or an indication 
that no server computer 12(m) is identified as being asso- 
ciated with the class (step 114). If the stub class loader 33 
determines that the result information comprises the identi- 
fication for the server computer 12(m), it (that is, the stub 
class loader 33) will return to step 101 to initiate commu- 
nication with the identified server computer 12(m) to obtain 
stub class instance for the class and method that may be 
invoked. On the other hand, if the stub class loader 33 
determines in step 114 that the nameserver computer 13 had 
provided an indication that no server computer 12(m) is 
identified as being associated with the class and method that 
may be invoked, the "class not found" exception may be 
indicated (step 115) and an exception handler called as 
described above. 

As noted above, the stub class instance 30 retrieved and 
loaded as described above in connection with FIG. 2 may be 
used in remote invocation of the method. Operations per- 
formed by the client computer 11(h) in connection with 
remote invocation of the method will be described in con- 
nection with the flow chart in FIG. 3. As depicted in FIG. 3, 
when a class instance 22 invokes a method, the control 
module 19 may initially verify that a stub class instance 30 
is present in the execution environment for remote method 
to be invoked (step 120). If a positive determination is made 
in step 120, the stub class instance 30 will be used for the 
remote invocation, and in the remote invocation will provide 
parameter values which are to be used in processing the 
remote method (step 121). Thereafter, the stub class instance 
30 for the remote method that may be invoked will be used 
to initiate communications with the server computer I2(m) 
which maintains the class for the remote method (step 122), 
in the process, the passing parameter values which are to be 
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used in processing the remote method will be passed. It will invoking program at run time, thereby obviating run-time 

be appreciated that, if the server computer 12(m) which is to incompatibilities which may result from mis-matches 

process the method is the same physical computer as the between the stub that is provided and the requirements of the 

client computer 12(h) which is invoking the method, the remote method that is invoked. 

communications can be among execution environments 5 It will be appreciated that a number of modifications may 

which are being processed within the physical computer. On be made to the arrangement as described above. For 

the other hand, if the server computer 12(m) which is to example, although the execution environment 20 has been 

process the method is a different physical computer from described as obtaining and loading stub class instances to 

that of the client computer 12(«) which is invoking the facilitate invocation of remote methods when references to 

method, the communications will be through the client 10 the remote methods are received, it will be appreciated that 

computer's and server computer's respective network inter- stub class instances may instead be obtained and loaded 

faces lS(n) and 16(m) and over the network 14. when the remote methods are initially invoked. Obtaining 

In response to the communications from the stub class and loadirj g of me stuD class instance for a remote method 

instance in step 122, the server computer 12(m), if necessary when a reference thereto is received will have the advan- 

establishes an execution environment 24 for the class which 15 lhat « ! he cla f tance wlU ^ present in the 

maintains the method that may be invoked, and the uses the ^^P 1 wheD the ' em ^ T ? aCtUaUy 

information provided by the skeleton 32 to create a class m ™£ e ?' >> rf the Wopnate stub , class ™ ton « 

■ . « «i_ * i / . i<vi\ it. not be located, the program or an operator may be notified 

instance 26 for that class (step 123) Thereafter, the server a , ^ eaf , ^ On the other hand, obtaining and loading of 

computer 12(m), under control of the control module 28, ±t stub class mstance fof , remote method when the method 

will process the method in connection with parameter values 20 j, lo be invoked may resuU in a delay of tne invoca t ion 

that were provided by stub class instance 30 (step 124). After the stub class inslance can be found( if the melhod is 

completing processing of the method, the server computer m fac , not mvoked even g a reference to it * rece ived the 

12(m), also under control of the control module 28, will stub dass instance ma no , Qeed , 0 te located ^ loaded 

inmate communications with the client computer's stub , t ^ ^ a ciated that a , em m accordance ^ the 

class mstance 30 to provide result information to the stub « • f * * j • i_ i * • i 

^ ^ h t« iuw iv^uit uiiui uiauuu iu amu 2 5 invention can be constructed in whole or in part from special 

class instance (step 125). In a manner similar to that ™ ir ™^ ^^v.™ „ r ^ n pn„r,i ^ r ^ m 

, ., , . v . r 7 . .... 11V . purpose nardware or a general purpose computer system, or 

described above in connection with step 102 ,f the server combination thereof, any portion of which may be 

computer 12(m) which processed the method is the same COQtrolled fe a ^ ^ ffl / ^ 

physical computer as the client computer 12(n) which ' , «f u !L ♦u- 

. ,.. r if _,, ./ ; 7 whole or in part comprise part of or be stored on the system 

mvoked the method, the communications can be among in * i „ ■» „ u i u 

' _ . , , . . , . 6 JU m a conventional manner, or it may in whole or in part be 

execution environments 24 and 20 which are being pro- * j j • * * i «i_ i_ 

. ... . T , " L , *: . - provided in to the system over a network or other mecha- 

cessed withm the physical computer. On the other hand, if c - • c *- • i 

it _ 4 's / \ t_ * i_ j . L j. nism for transferrmg mformation m a conventional manner, 

the server computer 12(m) which processed the method is a fa additi ft ^ be a dated ^ , he be 

dtferent physical computer from that of the chent computer ed and/or olheiwi ^ 0OIItro i lB d by means of inforaM _ 

^ft ^ 1 r 8 ^ ^' ? )m,,lunlcatl0 f 35 tion provided by an operator using operator input elements 

win be through the server computer s and chent computer's (no , sflown) ^ m £ fce oonne 5 ed , 2 ilectly £ the tem 

respective ne^ork interfaces 16(m) and 15(«) and over the ^ r whfch J information to th e system over a 

network 14. After the stub class instance 30 receives the network of omer mechamsm for transferring information in 

result information from the server computer, it may provide „ „ . & 

... - 4 . 4 iL . . t *L , . r .\ , . a conventional manner, 

result information to the class instance 22 which initiated the 40 ™ - . , . . 

remote method invocation (step 126), and that class instance The foregoing description has been limited to a specific 

22 can continue processing under control of the control «*°*>?** <* mvenUon It wiU be apparent, however, 

module 19 various variations and modifications may be made to the 

n . . ' . .- t , t t , , -g a j i • invention, with the attainment of some or all of the advan- 

• £Tri?^ • 'f ? 6 00 ,k . >W» of « he inventi °°- It is the object of the appended claims 

m that step that it does not have a stub class instance 30 that 45 ^.~u a 

. , f 4I _ . , « , , . . j to cover these and such other variations and modifications as 

is appropriate for the remote method that may be invoked, come ^ , he ^ idt and of ^ invention 

it may at that point call an exception handler (step 127) to what h claimed a / Qew ^ tQ be fc 

perform selected error recovery operations. LeUm patent of ^ United Sta(es ^ 

The invention provides a number of advantages. In L A method performed by a client in a data processing 

particular, it provides a new system and method for facili- 50 svs tem comprising- 

tatkg dynamic loading of a stub which enables a program ' idin to , stub ^ , caU mdudi 

that js operatmg in one execution environment to remotely m q{ a name ^ ^ a ^ anlete S r 

invoke processing of a method in another execution ^ inc , udi M identification of a class and renlote 

environment, so that the stub can be loaded by the program memod im lemente d by the class; 

when it is run and needed. In systems in which stubs are 55 . . . - , . 

compiled with the program, and thus are statically deter- ob £ mm S fr ° m J e name ™ ldenUfier of a *™ T 

mined when the program is compiled, they (the stubs) may . a . mc U , C f e . , , 

implement subsets of the actual set of remote interfaces retrieving, during runtime, a stub class mstance from the 

which are supported by the remote references that is scrver based OD the obtamed identifier; 

received by the programs which can lead to errors and 60 receiving a request to invoke the remote method; 

inefficiencies due to mismatches between the stub that is providing a second parameter value for the remote 

provided to a program and the requirements of the remote method to the stub class instance; 

procedure that is called when the program is run. However, providing, from the stub class instance, the second param- 

since, in the dynamic stub loading system and method, the eter value to the server; and 

stub that is loaded can be obtained from the particular 65 receiving by the stub class instance a result of an invo- 

resource which provides the remote method, it (the stub) can cation of the remote method based on the second 

define the exact set of interfaces to be provided to the parameter value. 
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2. The method of claim 1, wherein the remote method 
includes a parameter of a declared type and the second 
parameter value includes a reference to a remote object 
having a specified type that is a superset of the declared type. 

3. The method of claim 1, wherein the server and client 5 
are included in a single computer system. 

4. The method of claim 1, wherein the server and client 
are located in separate remote computer systems. 

5. The method of claim 1, wherein the stub class instance 
includes declarations for a set of one or more interfaces for 10 
the class that implements the remote method. 

6. A method performed by a server in a data processing 
system, comprising: 

providing, during runtime, an instance of a locally main- 
tained stub class to a client; 15 

receiving from the stub class instance a request to invoke 
a remote method implemented by a locally maintained 
class, the request including a parameter to the remote 
method; and 

20 

providing to the stub class instance a result of an invo- 
cation of the remote method based on the parameter. 

7. The method of claim 6, wherein the remote method has 
a method parameter of a declared type and the parameter in 
the request includes a reference to an object having a 25 
specified type that is a superset of the declared type. 

8. The method of claim 6, wherein the server and client 
are included in a single computer system. 

9. The method of claim 6, wherein the server and client 
are located in separate remote computer systems. 3Q 

10. A computer-readable medium including instructions 
for performing a method, when executed by a client, the 
method comprising: 

providing to a default stub class instance a call including 
an identifier of a name server and a first parameter 35 
value including an identification of a class and remote 
method implemented by the class; 

obtaining from the name server an identifier of a server 
that includes the class; 

retrieving, during runtime, a stub class instance from the 40 
server based on the obtained identifier; 

receiving a request to invoke the remote method; 

providing a second parameter value for the remote 
method to the stub class instance; 45 

providing, from the stub class instance, the second param- 
eter value to the server; and 

receiving by the stub class instance a result of an invo- 
cation of the remote method based on the second 
parameter value. 50 

11. The computer-readable medium of claim 10, wherein 
the remote method includes a parameter of a declared type 
and the second parameter value includes a reference to a 
remote object having a specified type that is a superset of the 
declared type. 55 

12. The computer-readable medium of claim 10, wherein 
the server and client are included in a single computer 
system. 
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13. The computer-readable medium of claim 10, wherein 
the server and client are located in separate remote computer 
systems. 

14. The computer-readable medium of claim 10, wherein 
the stub class instance includes declarations for a set of one 
or more interfaces for the class that implements the remote 
method. 

15. A computer-readable medium including instructions 
for performing a method, when executed by a server, the 
method comprising: 

providing, during runtime, an instance of a locally main- 
tained stub class to a client; 

receiving from the stub class instance a request to invoke 
a remote method implemented by a locally maintained 
class, the request including a parameter to the remote 
method; and 

providing to the stub class instance a result of an invo- 
cation of the remote method based on the parameter. 

16. The computer-readable medium of claim 15, wherein 
the remote method has a method parameter of a declared 
type and the parameter in the request includes a reference to 
an object having a specified type that is a superset of the 
declared type. 

17. The computer-readable medium of claim 15, wherein 
the server and client are included in a single computer 
system. 

18. The computer-readable medium of claim 15, wherein 
the server and client are located in separate remote computer 
systems. 

19. A data processing system, comprising: 

means for providing to a default stub class instance a call 
including an identifier of a name server and a second 
parameter value including an identification of a class 
and remote method implemented by the class; 

means for obtaining from the name server an identifier of 
a server that includes the class; 

means for retrieving, during runtime, a stub class instance 
from the server based on the obtained identifier; 

means for receiving a request to invoke the remote 
method; 

means for providing a parameter value for the remote 

method to the stub class instance; 
means for providing, from the stub class instance, the 

parameter value to the server, and 
means for receiving by the stub class instance a result of 

an invocation of the remote method based on the 

parameter value. 

20. A data processing system, comprising: 

means for providing, during runtime, an instance of a 
locally maintained stub class to a client; 

means for receiving from the stub class instance a request 
to invoke a method implemented by a locally main- 
tained class, the request including a parameter to the 
method; and 

means for providing to the stub class instance a result of 
an invocation of the method based on the parameter. 
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